In recent years, as in VoIP (Voice over IP), real time communication using an IP network has been widely used. There is an increasing number of cases where SIP (Session Initiation Protocol) is adopted as an international standard protocol for setting up connection between terminals at the opposite ends which execute real time communication such as a telephone terminal or a personal computer. In the present specification, a communication network in which signaling is executed using SIP is referred to as an SIP network.
Common structure of an SIP network is recited in Literature 3. An SIP network is formed of a location server, an SIP server and a user agent (UA). The user agent is described on page 76 of Literature 3 (which will be described later) as “SIP is based on a client-server model between end systems. Equivalent to the end system is a user agent (UA). User agent, which is more specifically an end system such as a telephone set or a personal computer, realizes services by transmitting and receiving a request and a response to/from these end systems”. In the present specification, the request recited in the above description will be referred to as an SIP request and a response as an SIP response.
As recited on page 77 of Literature 3, the SIP server has (1) a proxy server function of relaying an SIP request and an SIP response, (2) a redirect server function for use in inquiry of a destination of an SIP request, and (3) a registration server function of accepting registration of user agent information on an SIP network. Here, user agent information is, for example, URI (Uniform Resource Identifier) which is an identifier for accessing a user agent or an IP address to be used by a user agent. In the present specification, user agent information registered at the SIP server by a user agent will be referred to as registration information. The registration information is updated by using a REGISTER request as an SIP request.
Shown in FIG. 12 is an operation sequence in a case where user agents communicate with each other in a common SIP network. The figure, as recited in Literature 4 (which will be described later), includes an authentication method (digest authentication) of a user agent adopted when a common information communication provider sets up an SIP network.
First, a user agent (a calling side) transmits an INVITE request to an SIP server. In the present specification, an INVITE request transmitted first to the SIP server by the user agent (calling side) will be referred to as an initial INVITE request.
The SIP server having received the initial INVITE request from the user agent (calling side) calculates a nonce for use in digest authentication and returns an SIP response (407 proxy authentication required) with the nonce value added to the user agent (calling side). The user agent (calling side) hashes a secret (user identifier and a password) with the received nonce as a key. The result is stored in an Authorization header of an INVITE request and the obtained request is transferred to the SIP server. In the present specification, an INVITE request with an Authorization header added will be referred to as an authentication INVITE request.
The SIP server having received the authentication INVITE request executes authentication processing of the user agent (calling side). More specifically, (1) similarly to the user agent (calling side), hash a user identifier and a password of the user agent (calling side) by using own generated nonce value. (2) Compare the obtained result with an Authorization header value stored in the authentication INVITE request from the user agent (calling side) and when they coincide with each other, determine that the request is an authentication INVITE request from a proper user agent.
When as a result of the authentication processing, determining that it is an authentication INVITE request from a proper user agent, the SIP server transfers the authentication INVITE request to a user agent on a call arrival side (the user agent (call arrival side) in FIG. 12) designated by a To field.
Thereafter, after receiving the authentication INVITE request, the user agent (call arrival side) returns a provisional response (100 trying and 180 Ringing in FIG. 12) indicative of being in continuation of processing of the authentication INVITE request to the SIP server to call up a caller.
When the caller responds, the user agent (call arrival side) returns an SIP response (200 OK) indicative of completion of the processing of the authentication INVITE request to the SIP server. The user agent (calling side) issues an ACK request for informing the user agent (call arrival side) of the reception of the SIP response (200 OK) which is a final response to the authentication INVITE request. This leads to set-up of a session for a call between the user agent (calling side) and the user agent (call arrival side). At the time of completion of the call, a user agent who wants to end the call (the user agent (calling side) in FIG. 12) issues a BYE request for ending the session. By returning the SIP response (200 OK) after the BYE request processing, the user agent (call arrival side) having received the BYE request through the SIP server informs the completion of the session ending processing. As a result, the call between the user agent (calling side) and the user agent (call arrival side) ends.
A series of flow of the SIP response (200 OK) indicative of the end of the processing from the initial INVITE request to the BYE request shown in FIG. 12 is referred to as a “call flow (a flow of calling) in general, which is identified by a value of a Call-ID header stored in an SIP request and an SIP response. In other words, all the SIP requests and the SIP responses shown in FIG. 12 will hold the same Call-ID header value. Moreover, a common information communication provider needs to manage who is calling with whom in order to charge for the calling. Therefore, the SIP server is realized as a call stateful proxy that manages in which state of a call flow a generated call is. As a result, as shown in FIG. 12, all the SIP requests and the SIP responses in the call flow will pass through the same SIP server.
In order to realize high availability of a server which manages a state of processing of a series of requests transmitted from a client such as a state of a call at the above-described SIP server, there exists as a means for succeeding to contents of processing by a server by other server at the time of a failure of the server which is disclosed in Japanese Patent Laying-Open No. 2004-280738 (Literature 1). In the following, Literature 1 as one example of the related art will be described in detail with reference to the drawings. Reference numerals indicating the respective components which are illustrated in the figures showing the related art are different from the reference numerals indicative of the respective components shown in the specification of the present invention.
FIG. 13 is a diagram showing a structure of a proxy response device disclosed in Literature 1. In FIG. 13, the proxy response device recited in Literature 1 provides a function of monitoring occurrence of a failure of a plurality of servers and when a certain server develops a fault, causing other server to succeed to processing of the server developing a fault. For realizing the function, the proxy response device is described to have a unit set forth in the following.
“The proxy response device of the present invention has a unit which holds an address of a monitoring target server whose failure occurrence is to be monitored and of a spare server capable of responding in place of the monitoring target server to obtain a message transmitted and received by the monitoring target server from a communication network, a unit which detects a failure of the monitoring target server, a unit which, at the detection of a failure of the monitoring target server, rewrites, as to a message not responded among the obtained messages of a request from a client, a transmission source address into an address of the above-described proxy response device and transmits the obtained message to the spare server, and a unit which rewrites a transmission source address of a response message from the spare server into the address of the monitoring target server and relays the obtained message to the client.” (the paragraph 0012 in Literature 1 cited).
Shown in FIG. 14 is a hardware structure of an information processing device which realizes such a proxy response device. In FIG. 14, the structure is described as shown in the following.
“The information processing device realizing a proxy response device 1 includes a processor 100, a storage device 108, an input circuit interface 105 and an output circuit interface 107 which are to be connected to an IP network 6b, a reception buffer 104 for temporarily accumulating an IP packet received at the input circuit interface 105, a transmission buffer 106 for temporarily accumulating an IP packet to be transmitted by the output circuit interface 107, and an internal communication line such as a bus which connects these units. The storage unit 108 stores a program memory 101, a packet buffer 102 and a server management table 103. Recorded in the program memory 101 are various kinds of control programs which are executed by the processor 100 for realizing the proxy response device 1, and accumulated in the packet buffer 102 is an IP packet transmitted and received by a client 3 and servers 2a and 2b. The storage device 108 is formed of a semiconductor storage device or an external storage device such as a hard disk.” (the paragraph 0019 in Literature 1 cited).
In addition, thus structured proxy response device comprehends a processing condition of a server by introducing packet buffer management function set forth below in order to cause other server to succeed to processing contents of a server developing a fault, which is described as follows.
“The proxy response device 1 comprises the packet buffer 102 for managing a message transmitted and received between the client 3 and the servers 2a and 2b, which manages, in the lump, a message of a request transmitted by the client 3 and a message of a response from the servers 2a and 2b corresponding thereto as one unit (hereinafter referred to as a session). Session is registered in a session management entry 110-1, 110-2, . . . of the packet buffer 102.” (the paragraph 0022 in Literature 1 cited).
Example of a structure of the packet buffer is as shown in FIG. 15, which is described as follows.
“Each entry of the packet buffer 102 is formed of a session identifier 111, a client address 112, a server address 113, a client transmitted packet buffer 114 and a server transmitted packet buffer 115. The session identifier 111 is given a unitary identifier for identifying each entry. As the client address 112, an IP address of the client 3 which has transmitted a request is set. Set as the server address 113 is an IP address of the server 2a having received the request. In the client transmitted packet buffer 114, all the IP packets transmitted by the client 3 to the server 2a are stored as they are. Stored in the server transmitted packet buffer 115 are all the IP packets transmitted by the server 2a to the client 3 as they are (the paragraphs 0024 and 0025 in Literature 1 cited).
Next, operation of the proxy response device will be detailed with reference to the drawings.
FIG. 16 is a flow chart showing operation of the proxy response device. The operation is described as follows.
“All the IP packets flowing on the IP network 6b to which the proxy response device 1 is connected are obtained by the input circuit interface 105 and stored in the reception buffer 104. The processor 100, when there exists the above IP packet in the reception buffer 104, obtains one (step 170) and determines whether the obtained IP packet is related to the server 2a to be monitored based on whether a transmission source address 150 or a transmission destination address 151 of the above IP packet is coincident with a monitoring target server address 121 of the server management table 103. When failing to obtain an IP packet from the reception buffer 104 at Step 170, proceed to Step 175 (Step 171). When they are coincident, the processor 100 determines whether a packet kind 153 of the above IP packet is a cut-off request or not (Step 172) and when it is not a cut-off request, stores the above IP packet in a relevant entry of the packet buffer 102 (Step 173). The relevant entry is determined based on whether a pair of the transmission source address 150 and the transmission destination address 151 of the above IP packet is coincident with a pair of the client address 112 and the server address 113 (considered to be coincident even if the order is not the same). Storage destination will be, when a transmission destination of the above IP packet is a server, the client transmitted packet buffer 114 and will be the server transmitted packet buffer 115 when a transmission source of the above IP packet is a server. At this time, when there exists no relevant entry, generate a new entry. When the packet kind 153 is a cut-off request at Step 172, delete the relevant entry (Step 174). The processor 100 determines whether there exists a failure of a server having the monitoring target server address 121 in each entry of the server management table 103 (Step 175) and when there occurs a failure, executes proxy response processing (Step 177). Server failure existence determination method is not limited in particular, one example of which is monitoring all the sessions stored in the packet buffer 102 and when finding a session having no response from a server for a fixed time period, determining that the above server develops a fault. Another example is causing a server to execute a program of continuously transmitting a message indicative of no failure on the proxy response device 1, and when the proxy response device 1 fails to receive the message, determining that the server develops a fault. When first executing the proxy response processing in a certain session, execute processing preceding to a failure occurrence by using all the IP packets received to reproduce the same state. In addition, Step 177 is executed for each one IP packet to return to Step 170 after the execution.” (the paragraphs 0036 through 0042 in Literature 1 cited).
Thus, the proxy response device disclosed in Literature 1 as one example of the related art is characterized in storing all the IP packets transmitted from a client and a server and at the time of failure occurrence in the server, transmitting all the IP packets preceding to the failure occurrence to other server in order by the proxy response device in place of the client, thereby reproducing, on other server, the same state as that as of the failure occurrence at the server. This means causes other server to succeed to processing of a request from a client which is yet to be completed at the server.
Next, recited in Japanese Patent Laying-Open No. 2005-229273 (Literature 2) is a system as related art for avoiding an interruption state of a telephone set when a server develops a fault in the same telephone system whose technical range is the same as that of the present invention.
FIG. 17 is a diagram showing a principle structure of a server back-up device recited in Literature 2. The structure of the server back-up device is described as follows. “FIG. 1” in the following description corresponds to “FIG. 17” in the present specification.
“FIG. 1 is a block diagram of a principle structure of a server back-up device according to the present invention. The figure shows a principle structure of a server back-up device which is located between a plurality of telephone terminals connected to a network, e.g. an IP telephone terminal, and a server that executes switching connection of a call between internal terminals of the network and a call with the outside and which executes back-up of the server, which server back-up device 1 comprises at least a server failure detection unit 2 and a message transfer unit 3. The server failure detecting unit 2 is for detecting a failure of a server, which is equivalent to a call state management unit and an SIP message reading unit which will be described later, for example. During a failure occurrence period, the message transfer unit 3 rewrites a destination address in a predetermined message sent from a terminal side for the communication between terminals in the network from an address of its own device to an address of the other party side terminal and directly transfers the message to the other party side terminal without passing through the server, which is equivalent, for example, to an SIP message rewriting unit. In the exemplary embodiment of the present invention, the back-up device 1 further comprises an end point storage unit, e.g. an end point table, for storing an end point name and an IP address as a terminal identifier corresponding to each of a plurality of IP telephone terminals, so that the message transfer unit 3 is allowed to transfer a message based on storage contents of the end point storage unit. Predetermined message may be an invite message to be sent to the other party side terminal for requesting set-up of a call. The server back-up device of the present invention also comprises a server failure detecting unit and a message generating unit, e.g. an SIP message generating unit, for generating a response message corresponding to and in response to a predetermined message sent from a terminal in the network during a failure occurrence period and transmitting the response message to a transmission source terminal of the predetermined message. In the present exemplary embodiment, a predetermined message may be a register message to be transmitted from a terminal side for registration of its own terminal. Also in the present exemplary embodiment, the server back-up device further comprises a predetermined message reception time storing unit, e.g. an active call table, for storing the number of receptions of the predetermined message from the same terminal, so that the server failure detecting unit is allowed to detect a failure of the server when the number of receptions of stored messages in question exceeds a number determined in advance.” (the paragraphs 0010 through 0014 in Literature 2 cited).
Furthermore, shown in FIG. 18 is a structure of an entire system including the server back-up device recited in Literature 2. The server recited so far is equivalent to an IP Centrex server shown in FIG. 18. As illustrated in FIG. 18, with a spare system of the IP Centrex server not explicitly shown, the server back-up device is designed to be in charge of all the signaling from a user agent when the IP Centrex server develops a fault. In other words, the server back-up device transfers an SIP request from a user agent on a calling side to a user agent on a call arrival side. The server back-up device according to the exemplary embodiment therefore adopts a form of holding an end point storage unit for storing an end point name as an identifier of a user agent and an IP address of the user agent corresponding to each of a plurality of user agents in order to determine an IP address from an identifier of a user agent on a call arrival side such as a telephone number.
Next, operation of the server back-up device recited in Literature 2 will be described with reference to the drawings. FIG. 19 is a diagram showing operation executed when the IP Centrex server operates normally and FIG. 20 is a diagram showing operation executed when the IP Centrex server develops a fault.
These operations are described in Literature 2 as follows. In the following citation, “FIG. 4” is equivalent to “FIG. 19” in the present specification and “FIG. 5” is equivalent to “FIG. 20” in the present specification.
“FIG. 4 is a further detailed description of operation in the system when the Centrex server normally operates. Assume here that call-up from a terminal 121 starts a call with a terminal 122. An IP address of a back-up device 10 here is 111.1.1.10, an IP address of the terminal 121 is 111.1.1.1, an IP address of the terminal 122 is 111.1.1.2 and an IP address of an IP Centrex server 16 is 133.1.1.1. In FIG. 4, a session initiation protocol (SIP) message, for example, a register message or an invite message which will be described later, for setting up, maintaining and ending a session which is sent from the terminal 121 in FIG. 4 (1) reaches the back-up device 10 through a LAN 13, (2) is transferred by a path from the back-up device 10 to the IP Centrex server 16 via the LAN 13, a router 14 and an IP network 15, and (3) thereafter transferred to the back-up device 10 through a path leading from the IP Centrex server 16 to the back-up device 10 via the IP network 15, the router 14 and the LAN 13 and further transferred from the back-up device 10 to the terminal 122 through the LAN 13. Transmission and reception of an actual voice signal after connection of a call is completed between the terminals, that is, a media stream by the real time transport protocol (RTP) is executed directly between the terminals via the LAN 13 without passing through the back-up device 10. Also at the time of normal operation of the IP Centrex server 16, an actual voice signal is similarly transmitted and received directly between the terminals. FIG. 5 is a diagram for use in explaining operation executed at the time of the Centrex server failure occurrence in detail. Similarly to FIG. 4, when an invite message, for example, for setting up a call (1) is transferred to the back-up device 10 from the terminal 121 through the LAN 13, the back-up device 10 detects a failure occurring in the IP Centrex server 16 as will be described later and therefore, the back-up device 10 (2) directly transfers the message to the other party side IP telephone terminal 122 without transferring the same to the IP Centrex server 16 side to enable a call between two terminals. Transmission and reception of an actual voice signal after the completion of connection of a call between the terminals, that is, a media stream by the real time transport protocol, is directly executed between the terminals through the LAN 13 without passing through the pack-up device 10. Also at the time of normal operation of the IP Centrex server 16, an actual voice signal is similarly transmitted and received directly between the terminals.” (the paragraphs 0022 through 0024 in Literature 2 cited).
Thus, the server back-up device recited in Literature 2, when a failure occurs at the IP Centrex server, refers to information of an end point name and an IP address to change a destination of a received SIP request and directly transfers the SIP request to the user agent, thereby avoiding an interruption state of telephone caused by a failure of the IP Centrex server.    Patent Literature 1: Japanese Patent Laying-Open No. 2004-280738.    Patent Literature 2: Japanese Patent Laying-Open No. 2005-229273.    Non-Patent Literature 1: “SESSION INITIATION PROTOCOL TEXTBOOK” edited by Yasubumi CHIMURA and Toshifumi MURATA, pp 77-78, 2004, edited by Impress R&D Incorporation.    Non-Patent Literature 2: “Technical Specifications on Basic Call Interface for SIP Terminals Connecting with Provider's SIP Network”, Technical Specification No. TS-1006, 2004, edited by The Telecommunication Technology Committee.
The first problem is that the related art with the technique recited in Literature 1 as one example fails to normally end a call flow encountering a failure of a working SIP server.
The reason is that a state of the working SIP server at the time of failure occurrence cannot be reproduced on a spare SIP server.
Case where a state of the working SIP server at the time of failure occurrence cannot be reproduced on the spare SIP server is specifically illustrated. FIG. 21 is a sequence diagram showing an example where a state of the working SIP server cannot be reproduced by the spare SIP server in a case where a proxy response device is applied to an SIP network.
Shown in the figure is a case where there occurs a failure on the working SIP server after an SIP response (200 OK) indicative of the end of authentication INVITE request processing at a user agent (call arrival side) is transferred to a user agent (calling side) via the working SIP server.
In this case, the proxy response device transmits, to the spare SIP server, an initial INVITE request transmitted from the user agent (calling side) in order to reproduce a state of the working SIP server at the spare SIP server.
Then, the spare SIP server newly calculates a nonce value and transmits an SIP response (407 proxy authentication required) including the nonce value to the proxy response device. The proxy response device transmits the authentication INVITE request received from the user agent (calling side) to the spare SIP server.
The authentication processing at the spare SIP server, however, fails because a value stored in an Authentication header of the authentication INVITE request is hashed by using a nonce value generated by the working SIP server, so that it is different from that hashed by using a nonce value generated by the spare SIP server.
For the proxy response device failing to hold a user identifier and a password of the user agent (calling side) to avoid this situation, it is necessary to analyze the Authentication header value of the authentication INVITE request received from the user agent (calling side) to extract a user identifier and a password of the user agent (calling side). This, however, signifies breaking digest authentication, which is impossible.
As a result of the foregoing, the spare SIP server recognizes that a session of a call is yet to be set up between the user agent (calling side) and the user agent (call arrival side) although the user agent (calling side) and the user agent (call arrival side) are actually having a call. Even when the user agent (calling side) transmits a BYE request for ending the call at this state, the spare SIP server refrains from executing the BYE request because no session to be ended exists. Thus, a call flow encountering a failure of the working SIP server will not be ended normally.
The second problem is that in the related art with the technique recited in Literature 2 as one example, when a user agent makes a call at the occurrence of a failure in the Centrex server, no digest authentication can be executed.
The reason is that as shown in FIG. 12, although in digest authentication, it is necessary for the SIP server to calculate a nonce value for an initial INVITE request from a user agent (calling side) and return an SIP response (407 proxy authentication required) with the calculation result added to the user agent, the server back-up device recited in Literature 2 holds neither a function of calculating a nonce value nor a function of holding a user identifier and a password of the user agent, so that it is impossible to generate the SIP response (407 proxy authentication required).
The third problem is that in the related art with the technique recited in Literature 2 as one example, the degree of correspondence of the server back-up device with an increase in the number of user agents is low.
The reason is that according to the related art, for determining an IP address of a user agent (call arrival side), the server back-up device is designed to itself hold information of an identifier and an IP address of a user agent. As a result, as the number of user agents to be managed by the server back-up device is increased, a disk or a memory capacity for storing the information should be expanded.
The fourth problem is that in the related art with the technique recited in Literature 2 as one example, it is impossible to transfer an SIP request to other user agents than a user agent recited in information of an identifier and an IP address of a user agent held by the server back-up device.
The reason is that according to the related art, an IP address of a transfer destination of an SIP request is solved based on information held by the server back-up device. The problem, as recited in Literature 2 as “to this, when it fails to coincide with a value of an end point name in the end point table 23, refer to a value of Server Keep Alive and when the value is not less than 6, for example, generate a code 404 Not Found indicative of incapability of calling with the outside, set a transmission source address of an SIP message as a transmission destination address and transfer the transmission destination address, code and the SIP message to the SIP message generating unit 26. The SIP message generating unit 26 generates a message indicating that no connection to a communication partner side terminal is allowed and transmits the message to a terminal of the transmission source of the SIP message.” (the paragraph 0054 in Literature 2 cited), is yet to be solved by the server back-up device, and a system which notifies the user agent that no SIP request can be transferred is adopted.